Host behavior and network analytics based automotive secure gateway

ABSTRACT

Systems and methods for an automotive security gateway include an in-gateway security system that monitors local host behaviors in vehicle devices to identify anomalous local host behaviors using a blueprint model trained to recognize secure local host behaviors. An out-of-gateway security system monitors network traffic across remote hosts, local devices, hotspot network, and in-car network to identify anomalous behaviors using deep packet inspection to inspect packets of the network. A threat mitigation system issues threat mitigation instructions corresponding to the identified anomalous local host behaviors and the anomalous remote host behaviors to secure the vehicle devices by removing the identified anomalous local host behaviors and the anomalous remote host behaviors. Automotive security gateway services and vehicle electronic control units operate the vehicle devices according to the threat mitigation instructions.

RELATED APPLICATION INFORMATION

This application claims priority to U.S. Provisional Application No.62/565,486, filed on Sep. 29, 2018, incorporated herein by referenceherein its entirety.

BACKGROUND Technical Field

The present invention relates to gateway security of a network hub andmore particularly to host behavior and network analytics basedautomotive security gateway.

Description of the Related Art

Automotive vehicles become progressively more advanced as technology ingeneral, and automotive technology in particular, advances. Systems anddevices for various sensor tasks, safety systems, autonomous drivingsystems, infotainment devices, networking systems and other systems arebeing continuously added and improved upon. As a result, computingsystems in the vehicle or in communication with vehicle systems becomeincreasingly complex. As complexity increases, so does the risk ofattack and the variety of attack vectors that can risk the privacy,security and safety of vehicle occupants, as well as the integrity ofvehicle operations in general.

SUMMARY

According to an aspect of the present principles, a system is providedfor an automotive security gateway. The system includes an in-gatewaysecurity system that monitors local host behaviors in vehicle devices toidentify anomalous local host behaviors using a blueprint model trainedto recognize benign behaviors. An out-of-gateway security systemmonitors network traffic across remote hosts, local devices, hotspotnetwork, and in-car network to identify anomalous behaviors using deeppacket inspection to inspect packets of the network traffic. A threatmitigation system issues instructions corresponding to the identifiedanomalous behaviors of local host and remote host to secure the vehicledevices by removing the identified anomalous behaviors. Automotivesecurity gateway services and vehicle electronic control units operatethe vehicle devices according to the threat mitigation instructions.

According to another aspect of the present principles, a system isprovided for an automotive security gateway. The system includes anin-gateway security system that monitors local host behaviors in vehicledevices to identify anomalous behaviors, the in-gateway security systemincluding a system scanner that scans each of the vehicle devices toidentify in-gateway services and a blueprint modelling system trained torecognize benign local host behaviors. An out-of-gateway security systemmonitors network traffic across remote hosts, local devices, hotspotnetwork, and in-car network to identify anomalous behaviors, theout-of-gateway security system including a network screen that scans thenetwork traffic to identify out-of-gateway services and a deep packetinspector use deep packet inspection to inspect packets of the networktraffic to identify packet attributes including a packet source addressand a packet destination address. A threat mitigation system issuesthreat mitigation instructions corresponding to the identified anomalouslocal host behaviors and the anomalous remote host behaviors to securethe vehicle devices by removing the identified anomalous local hostbehaviors and the anomalous remote host behaviors. Automotive securitygateway services and vehicle electronic control units operate thevehicle devices according to the threat mitigation instructions.

According to another aspect of the present principles, a method isprovided for securing an automotive security gateway. The methodincludes monitoring local host behaviors in vehicle devices with anin-gateway security system to identify anomalous local host behaviorsusing a blueprint model trained to recognize secure local hostbehaviors. Network traffic is monitored across remote hosts, localdevices, hotspot network, and in-car network to identify anomalousbehaviors using deep packet inspection to inspect packets of the networktraffic. Threat mitigation instructions are issued corresponding to theidentified anomalous local host behaviors and the anomalous remote hostbehaviors a threat mitigation system to secure the vehicle devices byremoving the identified anomalous local host behaviors and the anomalousremote host behaviors. The vehicle devices are operated using automotivesecurity gateway services and electronic control units of a vehicleaccording to the threat mitigation instructions.

These and other features and advantages will become apparent from thefollowing detailed description of illustrative embodiments thereof,which is to be read in connection with the accompanying drawings.

BRIEF DESCRIPTION OF DRAWINGS

The disclosure will provide details in the following description ofpreferred embodiments with reference to the following figures wherein:

FIG. 1 is a block/flow diagram illustrating a high-level system/methodfor a host behavior and network analytics based automotive securitygateway, in accordance with the present principles;

FIG. 2 is a block/flow diagram illustrating a system/method for securityin an automotive security gateway, in accordance with the presentprinciples;

FIG. 3 is a block/flow diagram illustrating a system/method forin-gateway security in an automotive security gateway, in accordancewith the present principles;

FIG. 4 is a block/flow diagram illustrating a system/method forout-of-gateway security in an automotive security gateway, in accordancewith the present principles;

FIG. 5 is a block/flow diagram illustrating a system/method forgenerating alerts in response to risks identified by an automotivesecurity gateway, in accordance with the present principles; and

FIG. 6 is a flow diagram illustrating a system/method for host behaviorand network analytics in an automotive security gateway, in accordancewith the present principles.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In accordance with the present principles, systems and methods areprovided for host behavior and network analytics in an automotivesecurity gateway.

In one embodiment, an automotive gateway is provided with a securitysystem for monitoring both operating system events within the gateway,as well as network traffic from out of the gateway. The security systemmonitors event activity from each of the in-gateway services todetermine if a program includes a process, file or network threat to thevehicle or system.

However, because every specific event that poses a threat cannot beknown, the automotive security gateway includes a blueprint model thatlearns normal runtime behavior of each component of the in-gatewaysystem. The blueprint model can include, e.g. a whitelist of networkbehaviors, file behaviors, and process behaviors. As operating systemevents take place, the blueprint model learns normal runtime events.Thus, when an event is discovered that is not part of the normal runtimeevents, the security system can identify the event as anomalous. As aresult, the security system issues an alarm against the event. Thesecurity system can also verify each runtime program hash with a hash ofa corresponding original program. If the hash is modified, the integrityis compromised, and an alarm is issued. Similarly, the security systemcan issue an alarm when a program is not one of a set of live programsand when the program is unencrypted. Thus, security can be ensured byprotecting against anomalous programs and events occurring within thegateway.

The security system also monitors network traffic from out-of-gatewaydevices, such as, e.g., a vehicle electronic control unit (ECU), anin-vehicle Wi-Fi hotspot network, or other in-car network and out of carnetwork including an update service. To do so, the security systemanalyzes packets in the network traffic to determine if, e.g.,signatures in the packet are whitelisted or blacklisted, whetherencryption is used, whether the traffic content is of a known type, andwhether the network or destination and source addresses are whitelisted.To determine the whitelisting, a blueprint model can be trained, similarto the model described above, or a discrete list can be used. Ifout-of-gateway network traffic is determined to be a threat, an alarm israised. Thus, security can be ensured by protecting against anomalousnetwork traffic coming from outside of the gateway.

As a result, the security system can monitor both in-gateway andout-of-gateway activity concurrently to protect the vehicle systems fromattack from both sides. Thus, security of increasingly complex,sophisticated and connected vehicle systems can be protected despitesimilarly increasingly sophisticated and complex attacks and attackvectors.

Embodiments described herein may be entirely hardware, entirely softwareor including both hardware and software elements. In a preferredembodiment, the present invention is implemented in software, whichincludes but is not limited to firmware, resident software, microcode,etc.

Embodiments may include a computer program product accessible from acomputer-usable or computer-readable medium providing program code foruse by or in connection with a computer or any instruction executionsystem. A computer-usable or computer readable medium may include anyapparatus that stores, communicates, propagates, or transports theprogram for use by or in connection with the instruction executionsystem, apparatus, or device. The medium can be magnetic, optical,electronic, electromagnetic, infrared, or semiconductor system (orapparatus or device) or a propagation medium. The medium may include acomputer-readable storage medium such as a semiconductor or solid statememory, magnetic tape, a removable computer diskette, a random accessmemory (RAM), a read-only memory (ROM), a rigid magnetic disk and anoptical disk, etc.

Each computer program may be tangibly stored in a machine-readablestorage media or device (e.g., program memory or magnetic disk) readableby a general or special purpose programmable computer, for configuringand controlling operation of a computer when the storage media or deviceis read by the computer to perform the procedures described herein. Theinventive system may also be considered to be embodied in acomputer-readable storage medium, configured with a computer program,where the storage medium so configured causes a computer to operate in aspecific and predefined manner to perform the functions describedherein.

A data processing system suitable for storing and/or executing programcode may include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code to reduce the number of times code is retrieved frombulk storage during execution. Input/output or I/O devices (includingbut not limited to keyboards, displays, pointing devices, etc.) may becoupled to the system either directly or through intervening I/Ocontrollers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modem and Ethernet cards are just a few of thecurrently available types of network adapters.

Referring now in detail to the figures in which like numerals representthe same or similar elements and initially to FIG. 1, a high-levelsystem/method for a host behavior and network analytics based automotivesecurity gateway is illustratively depicted in accordance with oneembodiment of the present principles.

In one embodiment, a vehicle 10 includes an automotive security gateway200. The automotive security gateway 200 provides a hub for networks inthe vehicle 10 and systems for vehicle functionalities. Accordingly, theautomotive security gateway 200 includes a gateway for local hostservices. However, some of the local host services can present securityrisks to the vehicle 10. For example, attacks can be made againstvehicle 10 systems and functionalities that can hamper, e.g., vehicle 10safety systems such as, airbag operations, automated driving functions,anti-lock braking system (ABS), traction control, stability control, andother safety systems, as well was vehicle 10 operations, such as, e.g.,steering, throttle, braking, among others.

The attacks can come in the form of, e.g., corruptions to files, trojanhorse attacks, viruses, or any other attack that can spread through thelocal host devices and services. Therefore, the automotive securitygateway 200 can be used to protect against such attacks by, e.g.,monitoring each host device for anomalous processes. For example, theautomotive security gateway 200 includes local host devices forproviding the local host services, including, e.g., a gateway server400, an infotainment system 500, an update service 300, and any otherhost devices for providing local host services to the vehicle.

To secure each of the host devices 300, 400 and 500, events, such asoperating system (OS) events at each of the host devices 300, 400 and500 can be monitored for anomalies. Thus, the automotive securitygateway 200 can include a security system 600 to monitor operations ofeach of the updated network 300, the gateway server 400 and theinfotainment system 500, among any other local host devices providingvehicle functionalities.

While monitoring, the security system 600 can test OS events againstcriteria for secure operation. The criteria include information formaking determinations of secure events and attack threat events. Thus,the security system 600 can include security testing criteria thatincludes, e.g., a whitelist of safe events, a blacklist of unsafe orunknown events, a blueprint modelling system including, e.g., aprocessor to execute a model stored in a temporary or permanent memory,to learn safe or anomalous events, thresholds for change of eventproperties, and any combinations thereof. For example, when monitoringfiles, processes and network activities of a local host device program,a blueprint modelling system can be employed that has been trained torecognize safe events. Thus, when a file, process or network activityoccurs within the automotive security gateway 200 that is different fromthe safe event trained blueprint modelling system, the blueprintmodelling system identifies the file, process or network activity asanomalous, and thus a potential threat to the vehicle and to occupantsof the vehicle.

However, some functionalities of the vehicle 10 are provided fromoutside of the automotive security gateway 200, such as, e.g., softwareupdates, internet connections, device-to-vehicle connections, and otherout-of-gateway services. The out-of-gateway functionalities includedevices and services that are not secured within the automotive securitygateway 200 due to the external origination. As a result, theout-of-gateway services can also provide possible attack vectors tovehicle systems by communicating threats via network communications.

For example, a network or device connected to a network can attackvulnerabilities in various systems from the outside-in. Suchout-of-gateway services can include any route of communication such as,e.g., a wireless link for internet 110 and software updates. Thus, theout-of-gateway services 100 can present a risk to the security of thevehicle 10.

The hotspot network 130 can include a Wi-Fi network formed by thevehicle 10 with which external devices, such as, e.g., personalcomputers, smartphones, tablets, laptops, and any other Wi-Fi enableddevice, can communicate. Such a connection can be a medium through whichan attack can be made. This hotspot network 130 is not verifiablysecure. Thus, the hotspot network 130, should the vehicle 10 connect toit, could provide another medium in which an attacker can attack thevehicle 10. In-Car network 140 is the network connecting to internal cardevices and ECUs 120. ECUs represent Electronic Control Units which areembedded systems to control electrical systems in a car.

To guard against such out-of-gateway threats, the security system 600can monitor network traffic across multiple networks such as the hotspotnetwork 130, the in-car network 140, and out of the automotive securitygateway. Thus, when there is traffic across multiple networks and theautomotive security gateway 200, the security system 600 monitors thattraffic by, e.g., inspecting packets, or by other inspection techniques,to verify that the traffic is secure due to, e.g., the use ofencryption, a trusted source address or destination address, a trustedcontent type, among other possible indications of security.

The automotive security gateway 200 can respond to threats to thesecurity and integrity of automotive systems and functionalities. Oncean event or packet is identified as anomalous, the security system 600can issue an alarm for the anomalous event or packet. The alarm caninclude, e.g., an auditory or visual alarm through in car systems suchas, e.g., the infotainment system 500 for the user to receive, or a logon the gateway server 400 for diagnosis by a user or maintenanceprofessional, or even an automated response to safely bring the vehicle10 to a stop by, e.g., controlling the ECU 120 to adjust throttle,steering and braking. In addition to the alarm, the security system 600can also, e.g., terminate the anomalous event or packet, isolate andquarantine associated files and processes, disconnect devicesoriginating the anomalous even or packet, or take other actions toensure the security and integrity of the vehicle 10. Thus, the vehicle10 and the automotive security gateway 200 can identify threats fromboth internal and external systems and functionalities, thus providingsecurity to both sides of the automotive security gateway 200. As aresult, security and integrity is provided to the vehicle 10, even forsophisticated and networked vehicles.

Referring now to FIG. 2, a system/method for security in an automotivesecurity gateway is illustratively depicted in accordance with anembodiment of the present principles.

According to an embodiment of the present invention, the security system600 can monitor gateway services 610 a and network services 620 a toidentify anomalous service behaviors. Upon identifying an anomalousservice behavior of the gateway services 610 a and the network services620 a, the security system 600 issues an alarm 690 to address theanomalous behavior. However, the non-anomalous behaviors of the gatewayservices 610 a and the network services 620 a can be maintained asverified gateway services 610 b and verified network services 620 b,respectively.

To verify the gateway services 610 a, the security system 600 employsin-gateway security 630. The in-gateway security 630 includes a systemscanner 631 and an OS event monitor 640.

The system scanner 631 can be, e.g., a module executed by a processorand stored in a memory or storage that requests status updates from eachservice within the automotive security gateway. The request can include,e.g., a retrieval of OS event information for a current gateway service610 a, or a retrieval of OS event information from each gateway service610 a of the vehicle as a diagnostic. Thus, the system scanner 631 canretrieve OS event information such as, e.g., a running gateway service610 a of the vehicle and a corresponding process of the gateway service610 a, file of the gateway service 610 a and any network eventsassociated with the gateway service 610 a, among other event and eventrelated information. The system scanner 631 can operate continuously,collecting all OS event information in real time, or the system scanner631 can send requests to each gateway services 610 a of the vehicle on aperiodic basis, such as, e.g., every one second, five second, or tenseconds, or any other interval for sampling the gateway services 610 ato minimize a probability of an anomaly being undetected while ensuringcomputational resources are not compromised.

The OS event monitor 640 can inspect the sampled gateway services 610 ato verify the security of corresponding events. Threats in OS events cantake the form of attacks using, e.g., programs, files, processes,network events, or other attack vectors. Thus, the OS event monitor 640inspects each event for such attacks.

However, having knowledge of every possible attack can result in largestorage and memory resources being dedicated to maintaining a databaseof possible attacks because as computing systems, such as, e.g.,in-vehicle computing systems, become more sophisticated in operation,connectivity and security, attacks also increase in sophistication andvariety. Similarly, analyzing behaviors against every possible attack inthe database can be very computationally intensive. Thus, the OS eventmonitor 640 can identify threats without having information of allpossible attacks and attack vectors. Rather, the OS event monitor 640inspects OS events for behaviors known to be safe and normal to thesystem. Thus, once an event is identified as not having known safe andnormal behaviors, the OS event monitor 640 can flag the event asanomalous and issue an alarm.

The OS event monitor 640 can identify anomalous behavior of events usinga learned model. The model can include, e.g., a blueprint modellingsystem that is trained for normal OS event behaviors such as, e.g.,normal network connection requests, normal file access patterns andnormal process behaviors, among other behaviors. Thus, the blueprintmodelling system learns normal OS events such that when an OS eventstrays from normal behaviors, the blueprint modelling system can raisean alarm for the behavior being anomalous. Thus, even attacks of unknownorigin and unknown type can be identified by the OS event monitor 630while increasing computational efficiency of the security system 600.The gateway services 610 a that are not identified as anomalous, andthus normal, safe behaviors, can be passed to corresponding destinationsas verified gateway services 610 b.

To verify the network services 620 a, the security system 600 employsout-of-gateway security 650. The out-of-gateway security 650 includes anetwork screen 651 and a network packet monitor 640.

As network traffic enters the automotive security gateway 200, thesecurity system 600 employs the network screen 651 to sample packets ofthe network traffic. While the network screen 651 can pull each packetfrom the network traffic on a continuous basis for analysis by thenetwork packet monitor 660, the network screen 651 can alternatively,e.g., sample the network packets on a periodic basis, such as, e.g.,once per predetermined period of time, or one of every predeterminednumber of packets. The predetermined period of time can be setbeforehand by a user, or can be automatically determined according totraffic load to balance the computational costs of examining packetswith the risk of an attack threat not being found.

Packets selected by the network screen 651 can be analyzed by thenetwork packet monitor 660 to verify safe traffic and generate an alarmfor anomalous traffic. As described above, it is difficult and highlyresource intensive to include knowledge of every possible attack. Thus,the network packet monitor 660 can determine security threats byidentifying behavior that is outside of normal behaviors recognized assafe. For example, unencrypted traffic can be an indication of apossible attack, and thus be considered anomalous as not beingencrypted. Similarly, packets originating from and bound for unknownaddresses, or signed with either unknown or blacklisted signatures, thenthe packets can be considered anomalous despite not being confirmed asan actual attack. Similarly, connections and/or connection requests withunknown backend addresses and ports or with segregated subnetworks thenthe traffic can be considered anomalous. Other possible methods ofidentifying anomalous network services 620 b can also be implemented tosuch that the network packet monitor 660 can identify network trafficthat is anomalous. Thus, even network attacks of unknown origin andunknown type can be identified by the network packet monitor 660 whileincreasing computational efficiency of the security system 600. Thenetwork services 620 a that are not identified as anomalous, and thusnormal, safe behaviors, can be passed to corresponding destinations asverified network services 620 b.

In response to alarms raised by the in-gateway security 630 and theout-of-gateway security 650, a threat mitigation system 670 takes actionto mitigate possible attack threats corresponding to the alarms. Thus,the threat mitigation system 670 can inspect the alarm as well as, e.g.,the corresponding behavior, and generate a threat mitigation instruction692 to prevent a threat from spreading. For example, the threatmitigation system 670 can inspect the alarm and a log of thecorresponding behavior, and determine, e.g., an origin of an anomalouspacket, and in response, issue a threat mitigation instruction 692disconnecting the origin of the anomalous packet. Other responses toidentified threats can be taken commensurate with the type and degree ofthe threat to prevent corruption to vehicle systems and ensure thesafety of vehicle occupants.

Referring now to FIG. 3, a system/method for in-gateway security in anautomotive security gateway is illustratively depicted in accordancewith an embodiment of the present principles.

The OS event monitor 640 can inspect a gateway service 610 a. Throughinspection, the OS event monitor 640 determines whether the gatewayservice 610 a can be verified. Where the gateway service 610 a isverified, the OS event monitor 640 generates a verified gateway service610 b. Otherwise, the gateway service 610 a is exhibiting anomalousbehavior, and is thus at risk of attack. If the OS event monitor 640identifies the gateway service 610 a as an attack risk, then the OSevent monitor 640 generates an alarm 690.

The alarm 690 can include, e.g., diagnostic information of the anomalousbehavior so that the attack risk can be addressed. As a result, thealarm 690 can include, e.g., a log of the gateway service 610 a in,e.g., a temporary or permanent memory, as well as a quarantine of thegateway service 610 a to prevent a spread of the attack causing theanomalous behavior. The log can include, e.g., information identifyingthe gateway service, as well as the type of anomalous behavior and anyrelated gateway services 610 a. Thus, a system, such as, e.g., thethreat mitigation system 670 described above, can appropriately addressthe gateway service 610 a to mitigate any threats to the vehicle oroccupants.

The determination includes inspecting various parts of the gatewayservice 610 a, such as, e.g., a program included in the gateway service610 a and corresponding, e.g., files, processes, hashes, and networkconnections, among other event components. The OS event monitor 640 caninclude different analyses for, e.g., each of a program, a file and anetwork behavior. As such, the OS event monitor 640 can determine if agateway service 610 a includes any one or more of a program, a file or anetwork connection to analyze the gateway service 610 a for normal oranomalous behavior.

According to an embodiment of the present invention, the OS eventmonitor 640 can inspect the program of the gateway service 610 a toverify functionality. Thus, the OS even monitor 640 includes, e.g., anoperation monitor 642 to verify the normal operation of the gatewayservice 610 a according to whether a particular function is live. Thus,the operation monitor 642 can compare the program to a set of liveprograms 680 corresponding to all live gateway services 610 a. If theprogram is not included in the set of live programs 680, then thegateway service 610 a is malfunctioning. Thus, the operation monitor 642flags the gateway service 610 a as anomalous by, e.g., logging thegateway service 610 a as compromised and may include a threat to othergateway services 610 a or network services. As a result, the operationmonitor 642 generates the alarm 690 where the program of the gatewayservice 610 a is not one of the live programs 680.

However, even where the program is found to be in the set of liveprograms 680, and thus the gateway service 610 a is verified asoperational, the integrity of the gateway service 610 a can still havebeen compromised. A compromise of integrity can be indicated byanomalous changes to hashes of the gateway service 610 a program. As aresult, the OS event monitor 640 includes a hash inspector 643 toinspect hashes corresponding to each program. Thus, upon inspection ofthe gateway service 610 a and associated program, the hash inspector 643logs the hash of the gateway service 610 a program in, e.g., a temporaryor permanent memory. The hash inspector 643 can access the originalhashes of each live program 681 to determine an original hash of theprogram. However, if the hash inspector 643 is unable to verify the hashof the gateway service 610 a, then the gateway service 610 a iscompromised. As a result, the hash inspector 643 generates the alarm 690to indicate the compromised gateway service 610 a and a possible threatto other gateway services 610 a and network services.

In addition to verifying the operation and integrity of the gatewayservice 610 a, the OS event monitor 640 can include a system foridentifying anomalous behavior exhibited by the gateway service 610 a.To do so, the OS event monitor 640 includes a blueprint modelling system641 to recognize normal behaviors of each gateway service 610 a.However, processes, files and network connections each are defined bydifferent behavior patterns. Thus, the blueprint modelling system 641 istrained to recognize behavior patterns of each of processes, files andnetwork connections. Thus, the blueprint modelling system 641 canseparately recognize behavior patterns of processes, of files and ofnetwork connections to identify abnormal behavior patterns. As a result,the blueprint modelling system 641 includes a process model 644, a filemodel 646 and a network model 648 to identify anomalous behavior of agateway service 610 a exhibited by a process, a file and/or a networkconnection, respectively.

One possible indication of an attack is unusual process behavior. Undernormal conditions, the program of the gateway service 610 a includes aset of process behaviors including spawning other programs. Therefore,identification of unusual spawning can provide an effective andefficient means for identifying a possible attack. As a result, theprocess model 644 is a learned model to recognize normal processbehavior.

Process behavior can include, e.g., programs spawned by running aprogram, or other suitable behavior indicating normally functioningprocesses. As a result, the process model 644 is trained to recognize aset of programs that are normally spawned by executing each one of thelive programs 680. Accordingly, the gateway service 610 a is provided tothe process model 644. The process model 644 inspects the processes ofthe gateway service 610 a to identify spawned programs from executingthe program of the gateway service 610 a. The process model 644 thendetermines whether the spawned programs can be recognized as normallyspawned. Where any one of the spawned programs cannot be recognized asnormally spawned, the one of the spawned programs is consideredanomalous as spawning abnormal programs. As a result, process model 644generates the alarm 690 for the gateway service 610 a including an alertof the anomalous process behavior of the gateway service 610 a. However,where the process model 644 does recognize the spawned programs, theprocesses of the gateway service 610 a are verified.

Another possible indication of an attack on vehicle services is unusualfile access patterns. An attack can alter the files or file accesspatterns of a program of the gateway service 610 a. As a result,inspecting the program for unusual file access patterns can be aneffective and efficient method of identifying an attack. Thus, theblueprint modelling system 641 also inspects the gateway service 610 afor file behavior using a file model 646. The file model 646 is alearned model to recognize normal file access patterns, such as, e.g.,opening, closing, reading, writing, among other file behaviors. Similarto the process model 644, the file model 646 is trained against the fileaccess patterns of each possible gateway service 610 a. Thus, the filemodel 646 is trained to recognize normal file access behavior.

To test whether the gateway service 610 a exhibits normal file accesspatterns, the file model 646 tests file access patterns of the gatewayservice 610 a by testing file opening, closing, reading and writingpatterns. The file access patterns of the gateway service 610 a arecompared against the training of the file model 646. Where the filemodel 646 is unable to recognize the file access patterns as normal, thefile model 646 determines that the gateway service 610 a exhibitsanomalous file behavior. As a result, the file model 646 generates thealarm 690 including an alert of the anomalous file access behavior ofthe gateway service 610 a. However, where the file model 646 doesrecognize the file access patterns, the file access patterns of thegateway service 610 a are verified.

Similarly, network behavior can be analyzed for anomalous behavior. Onepossible indication of a network-based threat is connection to anunknown or abnormal network. The gateway service 610 a connecting to anunusual network can indicate that security has been compromised becausethe unusual network is not verified as secure. As a result, the unusualnetwork can be an attacking network or a device on the unusual networkcan be an attacking device. As a result, the blueprint modelling system641 includes a network model 648 that is trained to recognize normalnetwork connections to limit the risk of attacking devices from gainingaccess to vehicle services.

The network model 648 inspects network connections initiated by or tothe gateway service 610 a. The network connections of the gatewayservice 610 a are compared against the training of the network model648. Where the network model 648 is unable to recognize the networkconnects as normal, the network model identifies the gateway service 610a as exhibiting anomalous network behavior. As a result, the networkmodel 648 generates the alarm 690 including an alert of the anomalousnetwork behavior of the gateway service 610 a. However, where thenetwork model 648 does recognize the network connections, the networkconnections of the gateway service 610 a are verified.

The blueprint modelling system 641 can, therefore, verify the gatewayservice 610 a to generate a verified gateway service 610 b by inspectingthe gateway service 610 a for each of anomalous process behavior,anomalous file access behavior and anomalous network behavior. As aresult, the vehicle functionalities within the automotive securitygateway are secured and verified using the in-gateway security 640.Thus, attack threats and attack vectors are minimized in an efficientand effective manner.

Referring now to FIG. 4, a system/method for out-of-gateway security inan automotive security gateway is illustratively depicted in accordancewith an embodiment of the present principles.

According to an embodiment of the present invention, the network packetmonitor 600 can monitor network traffic, including, e.g., networkservices 620 a, for anomalous behavior and characteristics. Becauseout-of-gateway services, including network services 620 a originatingoutside of the automotive security gateway, are outside of the controlof the automotive security gateway, network connections can provide avector for attack from known and unknown malicious devices and networks.However, having knowledge of every attack possible by an out-of-gatewayservice is a very storage and computationally intensive task. However,knowledge of safe services, and associated behaviors and origins, isrelative space and computationally efficient. Thus, to effectivelyensure that only safe network packets of the network traffic areallowed, the network packet monitor 600 uses characteristics andattributes of the packets known to indicate secure network traffic ascriteria for verifying the network traffic. As a result, the networkpacket monitor 600 includes a deep packet inspector 661 to extract thepacket characteristics and attributes. Such characteristics andattributes can include, e.g., backend service address and ports,signatures, sub-network connections, among other packet characteristics.

As a result, upon detection by, e.g., the network screen 651 describedabove, a network service 620 a is inspected by a backend addressinspector 662. The backend address inspector 662 can ensure that thepacket provided by the network service 620 a is from a trusted source tobound for a trusted destination. Therefore, the source and destinationof network traffic can be verified, reducing the risk of unknown sourcesand destinations as vectors for attack.

Thus, the backend address inspector 662 leverages a set of known safeaddress and port combinations of trusted backend services. The set canbe included in a backend whitelist 681 provided to the backend addressinspector 662. By comparing the backend service address and ports of thenetwork service 620 a with the backend whitelist 681, the backendaddress inspector 662 can determine whether the network service 620 a isnormal or anomalous. Alternatively, a behavior model similar to theblueprint modelling system described above can be used, where thebehavior model is a backend service model that has been trained fornormal backend services and associated addresses and ports. The backendaddress inspector 662 can generate the alarm 690 upon an identificationof an anomalous backend service address or port. However, anidentification of the network service 620 a as communicating with anormal backend service address and port causes the backend addressinspector 662 to verify the backend service of the network service 620a. As a result, the automotive security gateway are secured from networkservices 620 a using the in-backend address inspector 662. Thus, attackthreats and attack vectors are minimized in an efficient and effectivemanner.

The network service 620 a can also be provided to an updater encryptionmonitor 664. The updater encryption monitor 664 determines whether thepackets of the network service 620 a correspond to an updater service.To do this, the updater encryption monitor 664 can utilize deep packetinspection to identify a traffic header of the network service 620 a andcharacterize the packet of the network service 620 a. Thecharacterization of packets of the network service 620 a can form adescription of a type of content being communicated by the networkservice 620 a corresponding to the traffic header. Some content typescan be associated with updater services. Thus, the results of the deeppacket inspection can be compared with the types of content included ina content whitelist 682. The content whitelist 682 includes informationregarding safe and normal updater services. Thus, the update encryptionmonitor 664 can identify normal network services 620 a as updaterservices.

Packets provided by an updater service to the vehicle systems have thepotential to affect files and settings for vehicle functions due to thehigh level of access provided for system updates. Thus, an attackthrough the updater service can comprise vehicle systems by, e.g.,installing backdoors, installing viruses, controlling vehicle functions,locking out occupants, disabling or enabling improper functions atimproper times, among other threats. Thus, encryption of network service620 a packets from an updater service is an effective and efficient wayof preventing such attacks by closing the vector of attack from externalinfluence. Therefore, the updater encryption monitor 664 examines thepackets of the network service 620 a to determine whether encryption isused on the network service 620 a. Encryption can be identified by,e.g., deep packet inspection, meta-data inspection, attempting to decodea packet, or other technique of identifying encryption. Thus, thenetwork service 620 a can be identified as having encryption on anupdater service or not. The updater encryption monitor 664 thengenerates an alarm 690 for network services 620 a that correspond to anupdater service but is not encrypted. In contrast, the updaterencryption monitor 664 can verify the encryption of an updater servicecorresponding to the network service 620 a. Thus, attack threats andattack vectors using an updater service are minimized in an efficientand effective manner.

Even where the backend service of the packets included in the networkservice 620 a is a verified backend service, the backend service maystill be insecure, thus providing an attack vector for maliciousactivity. As vehicles become more connect, for example, to the internetor to other devices via, e.g., a hotspot network. Such connections canbe susceptible to attack. Connections, such as Wi-Fi hotspots can beaccessed by other devices, thus increasing the risk of attack.Accordingly, Wi-Fi hotspots and other similar networks that can includeconnections to other unknown devices, can be segregated from each otherto limit exposure to possible attacks.

As a result, a sub-network monitor 666 is included in the network packetmonitor 660 to verify that sub-networks such as Wi-Fi hotspots aresegregated from each other and from in-car networks. Accordingly, thesub-network monitor 666 inspects the packets of the network service 620a to determine whether the network service 620 a communicates with anetwork that should be segregated. To do so, the sub-network monitor 666extracts the destination address and the source address from eachpacket. The sub-network monitor 666 can then compare the destinationaddress and source address to addresses associated with each networkidentified as a segregation network in a segregation list 683. Eachnetwork in the segregation list 683 has been identified as a sub-networkthat is to be segregated to prevent exposure to attacks from externaldevices. Thus, if either the source address or the destination addressof the packet matches an address of a segregated sub-network, thesegregated sub-network is in communication with an in-gateway network bythe network service 620 a, contrary to the identification as segregated.As a result, the network service 620 a is identified as insecure and thealarm 690 is generated.

The backend address inspector 662, the updater encryption monitor 664and the sub-network monitor 666 ensure that the network service 620 a iscommunicating with a safe backend service. However, even where thebackend service is trusted and the network service 620 a is encrypted,the network service 620 a can still be used as an attack vector with,e.g., trojan horse attacks, or other attacks that are passed along atrusted backend service. As a result, a signature inspector 668 inspectsthe contents of packets to determine whether the packets are signed withtrusted or malicious signatures to verify the contents of the packets assafe.

The signature inspector 668 can include information regarding secure andmalicious content signatures from a signature whitelist 684 and asignature blacklist 685, respectively. The signature whitelist 684 caninclude, e.g., a list of secure signatures formed from, e.g., a contentmodel that is trained updated according to content patterns duringnormal use. Thus, as content is provided by packets of the networkservice 620 a, when the content is found to be secure or insecure, thecontent model is updated to reflect the secure or insecure contentpattern. Thus, the signature whitelist 684 is built to includesignatures associated with secure content patterns.

The signature blacklist 685, however, can be built from, e.g., apre-determined list of signatures associated with malicious activity.The signature blacklist 685 can be pre-determined by, e.g., anintelligence service that researches and identifies malicious activity,or by other suitable sources of known malicious content.

A context signature is built from the signature whitelist 684 and thesignature blacklist 685. The context signature includes an entry for thelist of signatures in the signature whitelist 684, and an entry for thelist of signatures in the signature blacklist 685. The context signaturecan be, e.g., indexed by a network five tuple (source IP address, sourceport, destination IP address, destination port, and protocol).

The signature inspector 668 can inspect the packets and extractsignatures from each pack of the network service 620 a. The signatureidentifies the content of the packet. The five tuple (source IP address,source port, destination IP address, destination port, and protocol) isused as a key to find a corresponding context signature. Then, to verifythe packet, the signature of the packet is generated and comparedagainst the signature whitelist 684 and against the signature blacklist685. When the signature matches a whitelisted signature, the content andthe packet of the network service 620 a is verified. However, if thesignature matches a blacklisted signature, then the signature inspector668 generates the alarm 690.

If an alarm 690 is generated by any component of the network packetmonitor 660, then the offending packet and corresponding network service620 a is flagged as a potential threat. The alarm 690 can include, e.g.,identifying information of the network service 620 a, as well asinformation regarding the component responsible for generating the alarm690. Thus, the network service 620 a is identified as an attack threatwith information regarding the nature of the threat. Accordingly, thenetwork packet monitor 660 can identify and address potential attackvectors including the network service 620 a quickly and efficiently byemploying knowledge of normal and trusted network behaviors.

However, if the network service 620 a is inspected by each component ofthe network packet monitor 660 and is verified by each component, thenthe network service 620 a is output as a verified network service 620 b.The verified network service can, therefore, by passed on to theintended destination.

Referring now to FIG. 5, a system/method for generating alerts inresponse to risks identified by an automotive security gateway isillustratively depicted in accordance with an embodiment of the presentprinciples.

In response to alarms raised by the security system 600, a threatmitigation system 670 takes action to mitigate possible attack threatscorresponding to the alarms. As described above, an alarm 690 caninclude, e.g., information concerning the service that is the subject ofthe alarm 690, the behavior that triggered the alarm, as well as otherinformation, such as, e.g., a time stamp, network addresses associatedwith the service, other services that are immediately affected by theservice, and any other diagnostic information.

Thus, the threat mitigation system 670 can inspect the alarm as well as,e.g., the corresponding behavior, and generate a threat mitigationinstruction 692 to prevent a threat from spreading. For example, thethreat mitigation system 670 can inspect the alarm and a log of thecorresponding behavior, and determine, e.g., an origin of an anomalouspacket, and in response, issue a threat mitigation instruction 692disconnecting the origin of the anomalous packet. Other responses toidentified threats can be taken commensurate with the type and degree ofthe threat to prevent corruption to vehicle systems and ensure thesafety of vehicle occupants.

The threat mitigation instruction 692 can be provided to appropriatein-gateway devices 200 and out-of-gateways devices 100, such as thedevices described above with regards to FIG. 1. The threat mitigationinstruction 692 can be directed to a particular device by the threatmitigation system 670 according to, e.g., the type of service that isthe subject of the alarm 690. For example, the threat mitigation system670 can analyze the type of service and identify a device associatedwith such a type of service, such as, e.g., associating a vehicle ECUwith an anti-lock braking service.

As a result, the threat mitigation system 670 can communicate to anappropriate device to prevent harmful effects of a possible attack viathe service that is the subject of the alarm 690. For example, for ananomalous infotainment software update service, the threat mitigationsystem 670 can communicate with the infotainment system of thein-gateway devices 200 to discard or quarantine services originatingfrom the address associated with the anomalous infotainment softwareupdate service. As another example, for an anomalous ECU service, suchas, e.g., anti-lock braking that has raised an alarm 690 via thesignature inspector described above, the anti-lock braking service maybe from a blacklisted signature, thus indicating malicious softwaremasquerading as ECU services. Thus, the threat mitigation system 670 cancommunicate a threat mitigation instruction 692 to the ECU to disregardthe masquerading anti-lock braking service to ensure safe and effectivebraking of the vehicle.

According to aspects of the present invention, the threat mitigationinstruction 692 can include an instruction to use a prior verifiedservice of the type of the anomalous service. Thus, for the anomalousbraking service, the threat mitigation system 670 can issue the threatmitigation instruction 692 to provide a previously verified anti-lockbraking service, thus ensuring safe actuation of the vehicle brakes.Similar instruction can be provided to each system of the vehicle,including, e.g., the infotainment system, in-vehicle networks, hotspotnetwork, update systems, among others. Thus, the safe and secureoperation of the vehicle is enhanced by ensuring secure control ofvehicle systems via the automotive security gateway.

Referring now to FIG. 6, a system/method for host behavior and networkanalytics in an automotive security gateway is illustratively depictedin accordance with an embodiment of the present principles.

At block 701, local host behaviors are monitored in vehicle devices withan in-gateway security system to identify anomalous local host behaviorsusing a blueprint model trained to recognize secure local hostbehaviors.

At block 702, network traffic across remote hosts, local devices,hotspot network, in-car network are monitored to identify anomalousbehaviors using deep packet inspection that inspects packets of thenetwork traffic to recognize secure remote host behaviors.

At block 703, threat mitigation instructions corresponding to theidentified anomalous local host behaviors and the anomalous remote hostbehaviors are issued with a threat mitigation system to secure thevehicle devices by removing the identified anomalous local hostbehaviors and the anomalous remote host behaviors.

At block 704, the vehicle devices are operated using automotive securitygateway services and electronic control units of a vehicle according tothe threat mitigation instructions.

The foregoing is to be understood as being in every respect illustrativeand exemplary, but not restrictive, and the scope of the inventiondisclosed herein is not to be determined from the Detailed Description,but rather from the claims as interpreted according to the full breadthpermitted by the patent laws. It is to be understood that theembodiments shown and described herein are only illustrative of theprinciples of the present invention and that those skilled in the artmay implement various modifications without departing from the scope andspirit of the invention. Those skilled in the art could implementvarious other feature combinations without departing from the scope andspirit of the invention. Having thus described aspects of the invention,with the details and particularity required by the patent laws, what isclaimed and desired protected by Letters Patent is set forth in theappended claims.

What is claimed is:
 1. A system for an automotive security gateway, thesystem comprising: an in-gateway security system that monitors localhost behaviors in vehicle devices to identify anomalous local hostbehaviors using a blueprint model trained, using a blueprint modellingsystem, to recognize secure local host behaviors, the blueprintmodelling system comprising: a process modelling component trained torecognize normal process behaviors including programs normally spawnedfrom a program of each of the in-gateway services such that the processmodelling component identifies anomalous process behaviors that are notnormal based on an identification of programs being unusually spawnedfrom the program, the process modeling component being configured forgenerating an alarm including an alert for detected anomalous local hostbehavior; and a file modelling component trained to recognize normalfile access behaviors of the program of each of the in-gateway servicessuch that the file modelling component identifies anomalous file accessbehaviors that are not normal based on a file model trained against fileaccess patterns of each possible gateway service, the file modelingcomponent being configured for generating an alarm including an alertfor detected anomalous local host behavior, wherein the in-gatewaysecurity system includes a system scanner that scans each of the vehicledevices to identify in-gateway services; an out-of-gateway securitysystem that monitors network traffic across remote hosts, local devices,hotspot network, and in-car network to identify anomalous behaviorsusing deep packet inspection that inspects packets of the networktraffic; a threat mitigation system to issue threat mitigationinstructions corresponding to the identified anomalous local hostbehaviors and the anomalous remote host behaviors to secure the vehicledevices by removing the identified anomalous local host behaviors andthe anomalous remote host behaviors; and automotive security gatewayservices and vehicle electronic control units operating the vehicledevices according to the threat mitigation instructions.
 2. The systemas recited in claim 1, wherein the blueprint modelling system furthercomprises: a network modelling component trained to recognize normalnetwork connection behaviors for the program of each of the in-gatewayservices such that the network modelling component identifies anomalousnetwork connection behaviors that are not normal to generate the alarmfor anomalous behavior.
 3. The system as recited in claim 2, whereinfile events of the normal file access behaviors and the anomalous fileaccess behaviors includes file reading, file writing, file opening andfile closing.
 4. The system as recited in claim 2, wherein networkevents of the normal network connection behaviors and the anomalousnetwork connection behaviors includes source address, source port,destination address, destination port and protocol.
 5. The system asrecited in claim 1, wherein the out-of-gateway security system includesa network screen that scans the network traffic to identifyout-of-gateway services.
 6. The system as recited in claim 1, whereinthe out-of-gateway security system includes a backend address inspectorthat compares a packet source address and a packet destination addressto a backend whitelist of backend addresses to identify unverifiedbackend hosts corresponding to anomalous network traffic and generate anetwork traffic alarm.
 7. The system as recited in claim 1, wherein theout-of-gateway security system includes an updater encryption monitorthat uses deep packet inspection to compare a packet destination addressto a content whitelist of updater addresses to identify unverifiedupdater hosts and to identify an encryption status of the packetcorresponding to anomalous network traffic and generate a networktraffic alarm.
 8. The system as recited in claim 1, wherein theout-of-gateway security system includes a sub-network monitor thatcompares a packet source address and a packet destination address to asegregation list of sub-networks to be segregated to identify networktraffic in communication with one of the sub-networks to be segregatedand generate a network traffic alarm.
 9. The system as recited in claim1, wherein the out-of-gateway security system includes a signatureinspector configured to: match a key generated from the network fivetuple, source internet protocol address (IP), source port, destinationIP, destination port, and a protocol, to a key of a context signature,the context signature including a key, a list of a signature whitelistand a list of a signature blacklist; match a signature from a packet toa signature from one of the signature whitelist or the signatureblacklist upon matching the signature for the key, the second packetbeing subsequent to the first packet; and generate a network trafficalarm where the signature of the second packet matches a signature ofthe signature blacklist to inspect signatures of the network traffic.10. A system for an automotive security gateway, the system comprising:an in-gateway security system that monitors local host behaviors invehicle devices to identify anomalous local host behaviors, thein-gateway security system including: a system scanner that scans eachof the vehicle devices to identify in-gateway services; and a blueprintmodelling system trained to recognize secure local host behaviors, theblueprint modelling system comprising: a process modelling componenttrained to recognize normal process behaviors including programsnormally spawned from a program of each of the in-gateway services suchthat the process modelling component identifies anomalous processbehaviors that are not normal based on an identification of programsbeing unusually spawned from the program, the process modeling componentbeing configured for generating an alarm including an alert for detectedanomalous local host behavior; and a file modelling component trained torecognize normal file access behaviors of the program of each of thein-gateway services such that the file modelling component identifiesanomalous file access behaviors that are not normal based on a filemodel trained against file access patterns of each possible gatewayservice, the file modeling component being configured for generating analarm including an alert for detected anomalous local host behavior,wherein the in-gateway security system includes a system scanner thatscans each of the vehicle devices to identify in-gateway services; anout-of-gateway security system that monitors network traffic acrossremote hosts, local devices, hotspot network, in-car network to identifyanomalous behaviors, the out-of-gateway security system including: anetwork screen that scans the network traffic to identify out-of-gatewayservices; and a deep packet inspector that performs deep packetinspection to inspect packets of the network traffic to identify packetattributes including a packet source address and a packet destinationaddress; a threat mitigation system to issue threat mitigationinstructions corresponding to the identified anomalous local hostbehaviors and the anomalous remote host behaviors to secure the vehicledevices by removing the identified anomalous local host behaviors andthe anomalous remote host behaviors; and automotive security gatewayservices and vehicle electronic control units operating the vehicledevices according to the threat mitigation instructions.
 11. The systemas recited in claim 10, wherein the blueprint modelling system furthercomprises: a network modelling component trained to recognize normalnetwork connection behaviors for the program of each of the in-gatewayservices such that the network modelling component identifies anomalousnetwork connection behaviors that are not normal to generate the alarmfor anomalous behavior.
 12. The system as recited in claim 10, whereinthe out-of-gateway security system includes a backend address inspectorthat compares the packet source address and the packet destinationaddress to a backend whitelist of backend addresses to identifyunverified backend hosts corresponding to anomalous network traffic andgenerate a network traffic alarm.
 13. The system as recited in claim 10,wherein the out-of-gateway security system includes an updaterencryption monitor that uses the deep packet inspection to compare thepacket source address and the packet destination address to a contentwhitelist of updater addresses to identify unverified updater hosts andto identify an encryption status of the packet corresponding toanomalous network traffic and generate a network traffic alarm.
 14. Thesystem as recited in claim 10, wherein the out-of-gateway securitysystem includes a sub-network monitor that compares the packet sourceaddress and the packet destination address to a segregation list ofsub-networks to be segregated to identify network traffic incommunication with one of the sub-networks to be segregated and generatea network traffic alarm.
 15. The system as recited in claim 10, whereinthe out-of-gateway security system includes a signature inspectorconfigured to: match a key generated from the network five tuple, sourceinternet protocol address (IP), source port, destination IP, destinationport, a protocol, to a key of a context signature, the context signatureincluding a key, a list of a signature whitelist and a list of asignature blacklist; match a signature from a packet to a signature fromone of the signature whitelist or the signature blacklist upon matchingthe signature of the first packet with the key, the second packet beingsubsequent to the first packet; and generate a network traffic alarmwhere the signature of the packet matches a signature of the signatureblacklist to inspect signatures of the network traffic.
 16. A method forsecuring an automotive security gateway, the method comprising:monitoring local host behaviors in vehicle devices with an in-gatewaysecurity system to identify anomalous local host behaviors using ablueprint model trained, using a blueprint modelling system, torecognize secure local host behaviors, the blueprint modelling systemcomprising: training, by process modelling, to recognize normal processbehaviors including programs normally spawned from a program of each ofthe in-gateway services such that identifying, by the process modellinganomalous process behaviors that are not normal based on anidentification of programs being unusually spawned from the program,generating, by the process modeling, an alarm including an alert fordetected anomalous local host behavior; and recognizing, by filemodelling, after being trained, to recognize normal file accessbehaviors of the program of each of the in-gateway services such thatidentifying, by the file modelling, anomalous file access behaviors thatare not normal based on a file model trained against file accesspatterns of each possible gateway service, generating, by the filemodeling, an alarm including an alert for detected anomalous local hostbehavior, wherein the in-gateway security system includes a systemscanner that scans each of the vehicle devices to identify in-gatewayservices; monitoring network traffic across remote hosts, local devices,hotspot network, and in-car network to identify anomalous behaviorsusing deep packet inspection to inspect packets of the network traffic;issuing threat mitigation instructions corresponding to the identifiedanomalous local host behaviors and the anomalous remote host behaviorswith a threat mitigation system to secure the vehicle devices byremoving the identified anomalous local host behaviors and the anomalousremote host behaviors; and operating the vehicle devices usingautomotive security gateway services and electronic control units of avehicle according to the threat mitigation instructions.
 17. The methodas recited in claim 15, wherein the monitoring local host behaviorsincludes: identifying anomalous network connection behaviors that arenot normal using a network modelling component trained to recognizenormal network connection behaviors for the program of each of thein-gateway services to generate the alarm for anomalous behavior. 18.The method as recited in claim 15, wherein monitoring the networktraffic includes: performing deep packet inspection to identify a sourceaddress of a packet of the network traffic and a destination address ofthe packet of the network traffic; comparing the source address of thepacket and the destination address of the packet to verified backendaddresses and networks; and generating a network traffic alarm where oneof the source address of the packet or the destination address of thepacket is not one of the verified backend addresses and networks. 19.The method as recited in claim 15, wherein monitoring the networktraffic includes: matching a key generated from the network five tuple,source internet protocol address (IP), source port, destination IP,destination port, a protocol, to a key of a context signature, thecontext signature including a key, a list of a signature whitelist and alist of a signature blacklist; matching a signature of a packet to asignature from one of the signature whitelist or the signature blacklistupon matching the signature of the first packet with the key, the secondpacket being subsequent to the first packet; and generating a networktraffic alarm where the signature of the second packet matches asignature of the signature blacklist.